Diabetes mellitus is a disorder in which the pancreas cannot create sufficient insulin (Type I or insulin dependent) and/or in which insulin is not effective (Type 2 or non-insulin dependent). In the diabetic state, the victim suffers from high glucose, which may cause an array of physiological derangements (for example, kidney failure, skin ulcers, or bleeding into the vitreous of the eye) associated with the deterioration of small blood vessels.
Conventionally, a person with diabetes carries a self-monitoring blood glucose (SMBG) monitor, which typically requires uncomfortable finger pricks to obtain blood samples for measurement. Due to the lack of comfort and convenience associated with finger pricks, a person with diabetes normally only measures his or her glucose levels two to four times per day. Unfortunately, time intervals between measurements can be spread far enough apart that the person with diabetes finds out too late of a hyperglycemic or hypoglycemic condition, sometimes incurring dangerous side effects. It is not only unlikely that a person with diabetes will take a timely SMBG value, it is also likely that he or she will not know if his or her blood glucose value is going up (higher) or down (lower) based on conventional methods. Diabetics thus may be inhibited from making educated insulin therapy decisions.
Another device that some diabetics use to monitor their blood glucose is a continuous analyte sensor. A continuous analyte sensor typically includes a sensor that is placed subcutaneously, transdermally (e.g., transcutaneously), or intravascularly. The sensor measures the concentration of a given analyte within the body, and generates a raw signal that is transmitted to electronics associated with the sensor. The raw signal is converted into an output value that is displayed on a display. The output value that results from the conversion of the raw signal is typically expressed in a form that provides the user with meaningful clinical information, such as glucose expressed in mg/dL.
Where the analyte is glucose, and in the case of continuous glucose monitors (CGM), some CGMs provide for the activation of various alerts or alarms when the user's glucose value enters dangerous or undesired ranges. For example, many CGM's provide alerts if a user's glucose values stray into a range of mild hypoglycemia or hyperglycemia, and alarms if the situation becomes more dire. In some cases, such alerts/alarms use predictive algorithms to determine if the user is approaching a dangerous state and thus if an alert or alarms should be activated.
While useful, such alerts and alarms are not without problems. For example, users can quickly grow used to such alerts and alarms and begin to “tune them out” or otherwise ignore them. In some cases, users are unnecessarily re-alerted to a condition of which they are already aware. In many of these cases, “alert fatigue” can set in, causing the user to either disregard the alert or turn the same off without adequate consideration as to its cause or potential steps to address.
Other problems are now described. Examples will first be given in the category of “high” glucose alerts. In post meal time frames, users are often annoyed when they receive high alerts after eating and subsequent to dosing for a meal. Such high alerts can even occasionally lead to “stacking” or dosing insulin when insulin is already “on board”. In such cases, users are receiving alerts that they do not need to take action for, or which can cause users to take unnecessary action. In many cases, responses to such unnecessary post-meal alerts include that the user starts ignoring alerts, sets higher alert thresholds (and thus prevents the user from using a proper threshold as their target range boundary), or in some cases even turning off their high alerts. Such remedies can cause users to miss future unexpected high glucose levels.
Unnecessary re-alerts are another example of a high alert problem. In this case, users are annoyed when they receive multiple high alerts for the same height glucose event. Such situations are often caused by glucose levels hovering above and below their high threshold. In some cases users can activate a “snooze” time, and such as some degree of effectiveness. However, as with post-meal alerts, users do not want to be re-alerted for the same high event before their set snooze time. Remedies for these situations are similar to those above, including that users ignore alerts or turn off their high alert, again missing future unexpected high glucose levels.
Another “high alert” problem includes missed boluses. For example, users often receive a high alert if they have forgotten to dose for a meal. The high alert reminds users to dose, but the same is typically too late and does not prevent further rising. Remedies for missed boluses include that users set lower high alert thresholds, or set a rise rate alert. However, such remedies may result in additional false alerts for the user. In addition, the high alert and rise rate alert are sometimes not effective or accurate enough to catch missed boluses.
Another “high alert” problem is that certain users, e.g., those with a goal of tighter glucose control, want to be alerted if they are close but to below their high threshold for a long period of time. Such users may be using their high alert thresholds for their target zone boundaries, and in such cases, users may be unaware of how to accurately set or change their high alert thresholds.
Other high alert problems include that users do not know how to react to their initial alert settings. Still other high alert problems will also be understood.
Other problems exist in the use of “low alerts”. For example, alert fatigue as noted above can lead to mistrust in the system. For example, users may set a higher low alert threshold in order to give themselves more time to prevent severe hypoglycemic events. However, this may lead to more frequent alerts and consequent annoyance. For example, such users may receive many alerts of low blood glucose levels that do not lead to severe lows. While users desire more warnings for severe lows, frequent low alerts at a higher alert threshold cause mistrust in the system.
Relatedly, false alerts caused by faults such as compression may also cause mistrust in the system. In response to alert fatigue, users sometimes set lower alert thresholds, but then they have consequently less time to prevent urgent lows. As another remedy, users may turnoff low alerts and use fall rate alerts or urgent low alerts instead. For example, a fall rate alert may be set at −2 or −3 mg/dL. As yet another remedy, users may turn off their low alerts and rely on urgent low alerts instead. In many of these cases, user responses do not prevent low blood sugars.
Another “low alert” problem is similar to a high alert problem, and constitutes the issue of unnecessary re-alerts. That is, users are annoyed when they receive multiple low alerts for the same low glucose event. In many cases, such unnecessary re-alerts are caused by their glucose levels hovering just above or below their low threshold. Such may also be caused when users go above 55 but are still below their low threshold. In reaction to unnecessary re-alerts, users sometimes start ignoring alerts, or may turn off their low alert, or may over treat their condition, e.g., stacking carbs (which is often a particular problem at night). But such remedies cause the user to miss future unexpected low glucose levels.
Other low alert problems include that users may set their low alert threshold as the bottom boundary for their target range. Other low alert problems will also be understood.
Prior art in the field has dealt with certain alerting issues in the following ways.
In one way, as disclosed in U.S. Patent Publication No. US-2015/0289821, filed 16 Mar. 2015 and entitled GLYCEMIC URGENCY ASSESSMENT AND ALERTS INTERFACE, an actionable alert is disclosed as being provided based on a glycemic urgency index, which is a value that is more representative of a user's diabetic state than just a glucose value. Another publication, U.S. Patent Publication No. US-2014/0118138, granted as U.S. Pat. No. 9,119,528 on 1 Sep. 2015, and entitled SYSTEMS AND METHODS FOR PROVIDING SENSITIVE AND SPECIFIC ALARMS, discusses the occurrence of alarms that may be annoying to a user, but is directed to remedies such as waiting a particular time period or using a time delay. In yet another application, U.S. Patent Publication No. US-2015/0119655, filed 28 Oct. 2014 and entitled ADAPTIVE INTERFACE FOR CONTINUOUS MONITORING DEVICES, a user interface is adapted according to certain inputs, e.g., goals, population data, and the like. However, there is no disclosure of adapting the alerts themselves. In yet a further application, U.S. Patent Publication No. US-2014/0012510, filed 13 Mar. 2013 and entitled SYSTEMS AND METHODS FOR LEVERAGING SMARTPHONE FEATURES IN CONTINUOUS GLUCOSE MONITORING, disclosures are provided such that, e.g., if the user is in a meeting, an alert may be silenced. The reference discloses changing the timing of an alert, but only as part of a global setting, and not on a real-time basis. In yet another application, U.S. Ser. No. 62/289,825, filed 1 Feb. 2016, and entitled SYSTEM AND METHOD FOR DECISION SUPPORT USING LIFESTYLE FACTORS, feedback is provided to the user for decision-support purposes, e.g., informing the user of something useful for them and their treatment.
All of the above cited applications are owned by the assignee of the present application and herein incorporated by reference in their entireties.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.